home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / UNSPLIT / text0342.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  2.4 KB  |  50 lines
  1.  
  2. > Ehhmmm... this is probably a very stupied question, but...
  3. > Can't you make a mod player on the FPU in some way?? :-)
  4.  
  5. You could, but it would be so slow you would need at least 120Mhz FPU to make any
  6. significant savings in CPU time. Maybe even that's an underestimation.
  7.  
  8. The FPU is not a separate processor - it just equips the CPU with a bunch of new
  9. instructions. The CPU still has to execute them, and still has to wait for the
  10. results - even if the two devices can overlap their work to some degree.
  11.  
  12. Treating the FPU as an 'extra' processor will not solve any problems for us.
  13.  
  14. > I have never heard about anyone doing it, but 96-bit accuracy sound good for the sound quality.
  15. > If you can't do a modplayer, maybe a vector synthesizer? Sounds like a cool and wonderful crazy
  16. > project to me to implemetn some kind og music on the FPU. I understand that it can't probably be
  17. > sued for anything, but... :-))
  18.  
  19. FPU is very good for non-realtime audio (synthesis & processing), but that's about
  20. it. You need a DSP or some stand-in equivalent (CPU) to do anything in realtime.
  21.  
  22. > It's not such a big problem if you put some kind of music on the FPU either as it will be optional.
  23. > Waht can an FPU do anyway? I guess it can't do anything I want it to do. What about the blitter?
  24. > CAn't you use that to something wonderful crazy?? Isn't there some starnge silicon chips controlling
  25. > the ports as well (lan/parallel/serie)? Can't they be used to something?
  26.  
  27. The FPU can do nothing. It's not a processor - it just adds a bunch of new opcodes
  28. to the CPU, and takes over execution of these opcodes when the CPU hits them. You
  29. can't give the FPU a job and let it get on with it. It has no execution pipeline of
  30. it's own.
  31.  
  32. > As I said, this is probably a _very_ stupied question.... :-)
  33.  
  34. Well, you know the facts now! :)
  35.  
  36. > It would certainly make the collision detection EASIER to write, but it's worth the
  37. > little extra effort to make it run on every machine. The FPU becomes really useful
  38. > when developing the routines and testing them - but it's best avoided after that
  39. > stage.
  40.  
  41. > Maybe you could have two modes. One with high accuracy for those with a FPU and another
  42. > one for those without? :-)
  43.  
  44. I have an even better idea - just do one for the CPU! That way everybody gets the
  45. same version, and they are all fast, and they are all accurate. Forget the FPU - 
  46. It's of no practical use to us beyond the development & testing process.
  47.  
  48. Doug.
  49.  
  50.